【初心者向け】DLM (Data Lifecycle Manager)で周期的にEC2スナップショットを作成してみた

こんにちは！最近筋トレを始めて、毎日筋肉痛に苦しんでいるコンサルティング部のキムです。皆さんは運動してますか？体力の管理もセルフマネジメントの大事な部分だと思ってます！さて、案件で周期的にEC2のスナップショット（正確にはEC2にマウントされているEBSのスナップショット）作成をAmazon DLMを活かして設定してみたので、この内容を本ブログの記事として整理したいと思います。それでは、始めます！:)

#Amazon EC2

#Amazon DLM

#AWS IAM

#AWS

金泰雨

2019.08.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは！

最近筋トレを始めて、毎日筋肉痛に苦しんでいるコンサルティング部のキムです。皆さんは運動してますか？体力の管理もセルフマネジメントの大事な部分だと思ってます！

さて、案件で周期的にEC2のスナップショット（正確にはEC2にマウントされているEBSのスナップショット）作成をAmazon DLMを活かして設定してみたので、この内容を本ブログの記事として整理したいと思います。

それでは、始めます！:)

一般的なEC2のバックアップ方法

EC2 インスタンスをバックアップする方法は大きく二つの方式があります。

AMI作成
Snapshot作成

AMI作成の場合はインスタンスのメタデータおよびOSがインストールされたそのままのイメージ（一個以上のスナップショット + メタデータ）を作ります。 Snapshot作成の場合はインスタンスに付いているEBSボリュームのスナップショットが作成されます。

AMIバックアップのユースケースを一部だけ並べてみると以下のようになります。

バックアップされたインスタンスを緊急復元したい
インスタンス設定等が複雑で、設定が完了されたインスタンスのイメージを作りたい
ASG(Auto Scaling Group)から新たなインスタンスを自動生成したい

Snapshotバックアップのユースケースは以下のようになります。

OSとは別にデータのみバックアップしたい
作成されたスナップショットを基づき、様々なAMIを作成したい
Amazon DLMを活用して周期的なバックアップを有効化して、更にストレージコストを最適化したい（古いスナップショットは自動削除、それに同じブリューむについてのスナップショットは変更された部分のみ追加）

本記事は最後のAmazon DLM（Data Lifecycle Manager)に該当するバックアップ方式です。

Amazon DLM とは

Amazon DLM とは、Amazon EBS ボリュームをバックアップする為のSnapshotの生成 → 保存 → 削除のライフサイクルを自動化して、以下のようなメリットがあるサービスです。

定期的なバックアップスケジュールを実施して貴重なデータを保護する。
監査担当者または社内のコンプライアンスが必要とするバックアップを保持する。
古いバックアップを削除してストレージコストを削減する。

私は物事を理解する時にテキストを読むだけではなく、実際に操作して覚えたいので、DLMでスナップショットを作成してみます。:D

EC2インスタンス生成及びDLM Policyの作成

まず、AWSコンソールにログインしてEC2サービスコンソールに移動します。インスタンスタイプやOSタイプは何でもいいので、とりあえずEC2インスタンスを生成しました。 EC2スナップショットを作成するときにインスタンスにマウントされているストレージ毎にスナップショットが作成されるのを見たかったので複数のストレージを追加しました。 ec2_mount_multiple_ebs_volumes

インスタンスが生成された様子です。 ec2_instance_created

NameタグとDLM Policyから参照できるタグを付けました。 ec2_tags_attached

次はメニューからLifecycle Managerを押下します。 ec2_console_menu

Create Snapshot Lifecycle Policy ボタンをクリックすると、以下のようなDLM Policy作成ページに移動します。 dlm_policy_create_page

Policy は適当に下の画面のように入力しました。

本記事ではEBSではなくEC2のスナップショットを作成してみましたが、EBSを直接ターゲットとしてスナップショットを作成することも可能です。リソースタイプをInstanceにする場合は、該当EC2にマウントされている全てのEBSボリューム毎のスナップショットが作成されます。

Retention rule（保存ルール）は、該当ポリシーを適用して最大何個のスナップショットバージョンを保存するかの為の項目です。この項目によって古いバージョンのスナップショットは、DLMによって自動的に削除されます。

この記事の元記事の作成時点がJST20:09を過ぎていましたので、早く検証をする為に11:15 UTC(=20:15 JST)にしました。一つの注意点は、画面の中の説明の通り正確に11:15 UTCにバックアップが実施されるのではなく、設定した時間を基準として1時間以内にバックアップ作業が始まります。

Snapshots start being created within one hour of the specified start time.

dlm_policy_create_settings_1

その下のTag情報等はデフォルト値で置いて、一番下のPolicy Summaryを読み込んで設定した内容が間違いないようにもう一度確認しました。 dlm_policy_create_policy_summary

Create Policy ボタンを押して、policy idを確認しておきました。 dlm_policy_being_created

DLM Policy を設定した後のコンソール画面です。 dlm_policy_created_done

これでDLM設定は完了です！少し待ちながら実際にスナップショットが作成されるかを確認してみます。

Snapshot作成の確認

次はSnapshotsメニューに移動します。Policy作成段階で設定した時間からしばらく待てば（最長1時間）ポンとスナップショットが作成されます。下の画面のようにEC2にマウントしたEBSボリューム毎のスナップショットが作成されたのが分かりました！Yaay!! snapshots_created_by_dlm_policy

補足：作成されたSnapshotからEC2インスタンス化したい（復元したい）

追加で、作成されたスナップショットからEC2インスタンスを生成したい時は、つまり、スナップショットからインスタンスを復元したい場合は下のAWS公式文書を参照して頂ければと思います。私が実際に Linux 及び Windows インスタンスのスナップショットから復元する作業を読んでやってみました感想は、一つ一つ凄く丁寧に教えてくれる文書だと思いました。

さらにはまだディスクフォーマットが決まってないEBSの場合にはディスクフォーマットを定義してマウントする方法までに教えてくれるので、非常に良かったです。あ、それと当たり前のことだと思いますが、一つの留意点は、まずルートボリュームのスナップショットからインスタンスを作ってから追加のボリュームをマウントしなければならないということです。ルートボリュームではないボリュームからEC2インスタンスを立てると初期化段階で失敗しちゃいます。

参考になるAWS公式文書リスト

まとめ

DLMを活用して超簡単にEC2のバックアップができることが分かりました。それにもかかわらず、もしスナップショットからAMIを作るのがちょっと面倒だなぁと思う方がいらっしゃったら、弊社のopswitchも検討して頂ければと思います。 DLMとほぼ同じ便利さの上、スナップショットだけではなくAMIも一緒に作ってくれる機能も含まれています。

バックアップは選択ではなく必須ですね。未だにバックアップ設定をしていない方がいらっしゃれば今すぐにDLMポリシーを作成するのはいかがでしょうか :D